昨天的 Day 1，我留下了一個問題：
如果 AI 寫出來的東西不符合預期，問題真的都在 AI 嗎？
這也是我開始做 ClarifyBuild 的原因。
不過，在開始談「怎麼把需求說清楚」以前，我覺得還有一件事情得先釐清。
Vibe Coding 到底改變了什麼？
如果只是把原本自己寫 Code，換成叫 AI 幫忙寫，這個詞到底有什麼好紅的？
我自己想了一陣子，比較有可能的答案是：我們和「程式碼」之間的距離，變了。
「Vibe Coding」這個詞，是 Andrej Karpathy 在 2025 年 2 月提出的。
他當時描述了一種很極端、也有點玩笑意味的開發方式：幾乎不自己碰鍵盤、不仔細閱讀 AI 產生的程式碼差異，遇到錯誤就把錯誤訊息丟回模型，然後繼續讓 AI 修改。
甚至可以「忘記程式碼本身的存在」。
這其實和一般講的「AI 輔助寫程式」還不完全一樣。
到了現在，Vibe Coding 這個詞已經被用得更廣，有時候只要是透過自然語言和 AI 對話來完成程式，就會被放進 Vibe Coding 的範圍。
這個系列裡，我也會採取比較寬鬆、實務上的理解：
人主要負責描述想做什麼、判斷結果對不對；AI 則負責把這些意圖快速轉成可以執行的程式。
「AI 幫我寫」這件事，其實沒有在我腦中留太久。
留下來、一直盤旋不去的，是另一件事：
自然語言正在慢慢變成開發介面。
以前想做一個功能，我可能要先想到：
要用什麼框架？
資料要怎麼存？
元件怎麼切？
事件怎麼綁？
API 怎麼接？
這段語法怎麼寫？
現在，我可以直接告訴 AI：
幫我做一個待辦事項網站，
介面簡潔一點，
使用者可以登入，
可以新增、完成和刪除任務。
幾分鐘後，甚至幾十秒後，就可能已經有一個東西可以跑。
這件事情其實非常驚人。
過去從「腦中有一個想法」走到「畫面上真的出現東西」，中間隔著不少技術門檻。
現在這段距離被大幅縮短了。
原本可能是：
Idea
↓
Requirement
↓
Design
↓
Code
↓
Test
現在很容易變成：
Idea
↓
Prompt
↓
Generate
↓
Run
↓
不對，再叫 AI 改
↓
Generate
速度真的快很多。
但也因為太快，我開始發現另一個問題。
假設我跟 AI 說：
幫我做一個待辦事項網站，
介面好看一點，
而且要有登入功能。
這段 Prompt 看起來很合理。
AI 也完全有能力開始做。
可是仔細想一下，裡面其實還有一大堆事情沒有決定。
登入是 Email 密碼，還是 Google？
任務需要分類嗎？
需要截止日期嗎？
不同使用者的資料是不是要分開？
刪除任務要不要再次確認？
手機版需要做到什麼程度？
「好看一點」到底是什麼風格？
甚至連最基本的問題都還沒有回答：
這個網站到底是做給誰用的？
有趣的是，AI 通常不會因此停下來。
它很可能直接幫我做決定。
於是畫面出來了、登入頁也出來了、資料庫 Schema 甚至都可能幫我建好了。
然後我才開始說：
「等等，我不是要這樣。」
這也是我自己在使用 AI Coding 工具時，越來越在意的一件事。
AI 的能力提升之後，我們以前會卡住的地方變少了。
但那些原本應該先想清楚的事情，並沒有因此消失。
大型語言模型有一個非常方便的特性：
即使輸入不完整，它還是可以推測接下來可能是什麼。
寫文章很好用。
Brainstorm 很好用。
寫 Code 當然也很好用。
但到了需求上，這個能力有時候反而會造成一個很微妙的問題。
我們沒有講清楚的地方，AI 會幫我們補。
而且它補得通常還滿合理。
合理到第一次看到時，我甚至可能覺得：
「好像可以耶。」
可是當功能越做越多，前面那些沒有真正決定過的事情，就會慢慢浮現。
這時候再修改，影響的可能已經不只是一個按鈕。
資料結構、頁面流程、權限、API，全部都有可能一起被牽動。
所以我現在越來越覺得，AI Coding 最危險的地方，未必是它完全寫錯。
反而是：
它可以非常快速地，把一個還沒想清楚的想法，做成一個看起來已經很完整的東西。
Stack Overflow 2025 Developer Survey 裡，有 84% 的受訪者正在使用或計畫使用 AI 開發工具；但同一份調查中，最多開發者提到的挫折，是 AI 給出的解法「幾乎是對的，但又沒有完全對」。
這個「Almost right」我覺得很值得注意。
因為它和我想處理的問題很接近。
程式可能可以跑。
畫面可能也有出來。
但「可以跑」跟「這就是我要的」，中間還有一段距離。
以前開發一個功能，很多時間花在實作。
怎麼寫、怎麼 Debug、怎麼查文件，本身就是很大的成本。
所以即使需求還沒有完全清楚，我們也可能一邊開發、一邊慢慢想。
現在 AI 把其中一部分實作成本壓低了。
一個模糊的想法，可以非常快地變成程式。
這時候，原本藏在 Coding 前面的問題就變得更明顯：
我要解決什麼？
哪些功能真的需要？
哪些功能現在不要做？
什麼狀況才算完成？
AI 可以自行決定什麼，又有哪些事情必須先問我？
DORA 在 2025 年的 AI-assisted Software Development 研究裡，把 AI 描述成一種「Amplifier」。
它會放大一個團隊原本存在的優勢，也會放大原本存在的弱點。
我滿喜歡這個說法。
如果需求已經想得很清楚，AI 可以把實作速度放大。
但如果需求本來就是模糊的，那 AI 也可能只是讓我們更快地往一個還沒確認的方向前進。
所以對我來說，Vibe Coding 帶來的其中一個改變就是：
當寫 Code 不再是唯一主要瓶頸，如何把 Intent 說清楚，開始變得更重要。
這也是我重新整理 ClarifyBuild 流程之後，現在最核心的一條線：
Idea
↓
Clarify
↓
Scope
↓
Spec
↓
Prompt
↓
Build
↓
Validate
AI 能寫得這麼快，這件事本身我完全樂見。
我想加的，只是按下「開始 Build」之前，那一小段很短的思考時間。
先問幾個問題。
先把模糊的地方找出來。
先決定這次到底要做多少。
再把這些決策整理成 AI 比較容易執行的 Spec。
最後才交給 Coding Agent。
ClarifyBuild 想做的，就是中間這一段。
Idea → ??? → Prompt
把那個 ??? 補起來。
Day 2 到這裡，我甚至還沒有真正開始做 ClarifyBuild 的 UI。
但我反而覺得這一步很重要。
因為如果連自己想解決的問題都沒有定義清楚，然後馬上打開 Claude Code、Codex、Cursor 開始做……
好像剛好又重演了這個系列想處理的問題。
所以今天先停在這裡。
先把 Vibe Coding 帶來的改變畫清楚。
目前我的答案是：
Vibe Coding 讓「想法 → 程式」變得非常快，也因此讓「想法到底清不清楚」這件事更難忽略。
而下一個問題也跟著出現了：
所謂的「需求沒說清楚」，到底是哪裡沒說清楚？
這就是明天 Day 3 要開始拆的東西。
Day 2 完成。
明天見。
iThome鐵人賽
看影片追技術